Role-Based Access Control (RBAC) mechanisms enable software applications and network resources to limit or control access based on the business or operational role of a user or a group of users. Numerous RBAC mechanisms have been developed in the past for various purposes and contexts, but have had numerous disadvantages.
Typically, the RBAC mechanisms are implemented as a centralized server with a secure repository, requiring a client software element that must be installed on every user machine. In such implementations the RBAC mechanisms include complex security mechanisms and require application software developers to learn a specific API and to write code against it. While RBAC has great utility in many contexts, these disadvantages have reduced the ubiquity of RBAC mechanisms and have imposed high development costs on applications and systems that need to use RBAC.
In terms of simplicity, one of the most well-known and easy to write code against subsystems in a computer system is the filesystem. A typical filesystem usually manages files which are organized in a number of directories. The filesystem may manage a wide variety of file types with respect to file formats and file purposes. For example, files may be stored in the file system in text, binary, or any software-specific format. Also, with respect to their functions, files may be classified as boot files, system files, application specific files, device files, special files, or data files. However, all the files in a filesystem, regardless of their type or purpose, are managed by the Operating System (OS) by using well-defined, easy to use, simple, and thoroughly tested file-management facilities.
The OS filesystem facilities include various APIs and system calls to control access to and perform operations on the files. These facilities are well-known and application software developers routinely use them. Depending on the OS, the filesystem facilities may consist of a library of system calls, or of a number of well-defined APIs. The system calls and the APIs include various routines for performing operations on the files. Such operations typically include opening a file, closing a file, reading from a file, searching through a file, writing to the file, appending to the file, and deleting the file. Any of these file operations, however, is performed only if the user requesting the operation is allowed access to the file by the OS.
For this reason, the OS filesystem system calls and APIs also include various routines for managing file security and file access. These routines depend on the user and group authentication and authorization mechanism of the particular OS to control the access of the users and groups to files in the filesystem. Different operating systems use different user and group authentication and authorization mechanisms, but typically a user is associated with a username and a password, and a user may also belong to one or more groups of users.
The different operating systems employ different schemes to control access of users and groups to the files in the filesystem. Without exception, however, all operating systems provide a set of file attributes which are used by the filesystem routines to manage and control access to the files. Examples of such attributes include an owner user identifier (UserID) that identifies the owner of the file, a group identifier (GroupID) that identifies a group of users, and an Access Control List (ACL) which includes the identifiers of a number of users or groups. In addition to identifiers identifying users, file attributes called permissions are also used to indicate what, if any, file operations are allowed on the file and which user or group is allowed to perform which file operation.
The operating systems usually handle with ease the associating of users and groups with functional or operational roles. As described above, the OS filesystem calls and APIs for controlling user or group access to files are also well-known and easy to use. However, the existing RBAC mechanisms cannot manage a wide variety of computer resources in a low-cost, low-impact, and client-software efficient manner, and invariably suffer from a number of disadvantages, some of which where mentioned above.
Based on the foregoing, there is clearly a need for an RBAC system that requires minimal client software and otherwise has a greatly reduced infrastructure. There is also a need for an RBAC system that still provides security, that can run in a localized manner on a single machine, and that requires applications only to use existing APIs.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.